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1 Introduction 

Computer software is playing an increasingly impor- 
tant role in safety-critical embedded computer systems, 
where incorrect operation of the software could lead to 
loss of life, substantial material or environmental dam- 
age, or large monetary losses. Although software is a 
powerful and flexible tool for industry, these very ad- 
vantages have contributed to a corresponding increase 
in system complexity. It is becoming clear that the 
power software can bring to a system can also under- 
mine the ability of the analyst to comprehend, and con- 
sequently control, the system's behavior. 

In a previous investigation, the Irvine Safety Re- 
search Group, under the leadership of Dr. Nancy 
Leveson, developed a requirements specification lan- 
guage called the Requirements State Machine Lan- 
guage (RSML) suitable for the specification of safety- 
critical control embedded systems [14, 15]. To make 
RSML suitable as a requirements specification lan- 
guage usable by all stake holders in a specification 
effort, the syntax and semantics were developed with 
readability, understandability, and ease of use in mind. 
The usefulness of the language was demonstrated 
through the successful development of a requirements 
specification for a large commercial avionics system 
called TCAS II (Traffic alert and Collision Avoidance 
System II) [14, 15]. Furthermore, we have developed a 
collection of automated analysis procedures that check 
an RSML specification for desirable properties such as 
completeness, consistency, and determinism [10, 11]. 

However, even if a requirements specification is read- 
able, understandable, and can be shown to be complete 
and consistent, designing and developing production 
quality code from such a black-box high-level specifica- 
tion can be a time consuming and error prone process. 

To simplify and automate the design and implemen- 
tation process, we have investigated the possibility of 
automatically generating code from RSML specifica- 
tions. The semantics of RSML is relatively simple 
and is defined as a composition of simple mathemat- 
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ical functions denned by the state transitions in the 
model [11]. We have developed a tool that translates 
an RSML specification to executable code. The trans- 
lation closely follows the formal semantics of RSML 
and, thus, makes verification of the correctness of the 
generated code simple. For the translations where 
this straightforward approach generates obviously in- 
efficient code, we have defined easily verifiable auto- 
mated correctness preserving optimizations. 

Our goal is to generate production quality code di- 
rectly from RSML specifications with as little human 
intervention as possible. To determine if this is a re- 
alistic goal and to get some early feedback on our ap- 
proach, we have applied our translation technique to 
several small sample RSML specifications, including a 
part of the TCAS II requirements specification. Initial 
results show that the generated code is approximately 
5-10 times slower and about twice as large as highly op- 
timized hand generated code. These results show that 
automatic code generation is feasible, at least in the 
domain for which RSML was developed, and that our 
easily verifiable translation is a promising start. 

A program transformation approach provides a 
means of keeping a specification and its implementa- 
tion consistent. When a change is needed, the change 
is made in the high-level specification rather than in 
the source code. The code is then simply regener- 
ated from the specification. Furthermore, provided 
the transformations preserve correctness, the generated 
code is guaranteed to correctly implement the specifi- 
cation and satisfy all properties that have been proven 
about the specification. 

Generating executable code from some higher level 
notation has been an active research area since the 
development of the first compiler. Although a trans- 
formational approach does not solve the fundamental 
problems of complex system development, it allows us 
to work in a notation suitable for the problem domain, 
in our case RSML and safety-critical embedded control 
systems, and in that way eliminate many accidental 
problems associated with obscure notation and man- 
ual coding. 

Many systems that transform specifications into ex- 
ecutable code have been developed oyer the years. The 
following overview is by no means an exhaustive de- 



scription of such systems, but rather a brief summary 
of some of the main transformational approaches. 

Early transformational systems, such as the TI 
(Transformational Implementation) system [1], CIP 
(Computer-aided, Intuition-guided Prograinming) [2], 
and KIDS (Kestrel Interactive Development Sys- 
tem) [16] , were designed for use in general purpose pro- 
gramming. These types of systems are usually based 
upon wide spectrum languages that are iteratively 
transformed into lower level constructs. One of the 
major drawbacks to this approach is the need for the 
user to guide the transformational process and provide 
application-specific domain knowledge to the system. 
These systems can usually only perform a few sim- 
ple transformations automatically, requiring the user 
to make decisions relating to complex data types and 
algorithms. The level of automation of such general- 
purpose systems varies, but it seems unlikely that a 
fully automatic transformational system can be built 
using this approach. 

A different approach to code generation is taken by 
the Statemate system [6, 7, 12]. Statemate is a sys- 
tem for developing software for reactive systems that 
supports automatic generation of C, Ada, or VHDL 
code. A Statemate specification consists of three parts 
(1) a structural view defined by module charts, (2) a 
functional view defined by activity charts, and (3) a 
dynamic view defined by Statecharts. 

The module charts are used to decompose a system 
into its main components. The functional decomposi- 
tion of the components is captured using the activity 
charts. The modeling in Statemate is based on the 
stepwise refinement paradigm. The activity charts can 
be iteratively refined until atomic activities (or basic 
activities) can be described as simple transformations 
using a high-level programming language, for example, 
C or Ada. The activity charts fully capture the func- 
tionality of a system. 

Statecharts are finite state machines augmented 
with hierarchy, parallelism, and modularity. In State- 
mate, the Statecharts are used to define the dynamic 
behavior of a system, that is, they determine when ac- 
tivities defined by the activity charts should be exe- 
cuted. 

The transformation of a Statemate specification into 
code involves translating the activities to executable 
code. Activities with fully defined functionality will be 
directly translated to code, while activities with under- 
specified functionality will be translated into stubs that 
can be completed manually. The Statecharts are trans- 
lated to a control program that determines when the 
code for representing the different activities will be in- 
voked. The code generation is fully automated and 
results in what is considered to be prototype code. 

The Statemate approach is similar to the RSML ap- 
proach in some aspects. First, both approaches target 
embedded reactive systems and both are based on a 
state-based modeling approach. In fact, RSML is in- 
spired by the Statecharts formalism and includes sup- 
port for parallelism and hierarchical states. 
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Figure 1: An example of a state machine. 



Despite the similarities between Statecharts and 
RSML, the two modeling approaches are quite differ- 
ent. The main difference is that in RSML the full be- 
havior of the system is captured using only the hier- 
archical state machine: RSML does not support activ- 
ity charts and module charts. In the Statemate ap- 
proach, the state machines are mainly used to control 
the scheduling of activities. Thus, the states reflect 
processing activity, that is, the states indicate which 
activities are currently executing. In RSML, on the 
other hand, the state machines are used to model the 
behavior of the physical components in a system: the 
states are used to visualize the system state. 

During a large case study (TCAS) [3, 4, 15], we 
found that using the state machines to highlight the 
state of the system made it easy for the engineers (do- 
main experts) such as avionics engineers, pilots, air 
frame manufacturers, and FAA representatives to un- 
derstand and validate the requirements specification. 
The reason for this, we believe, is that an RSML speci- 
fication is conceptually close to the application domain 
and becomes easier to validate. For a thorough discus- 
sion on this topic, the reader is referred to [15]. 

This difference in modeling approach leads to a dif- 
ferent approach to code generation. While Statemate, 
for example, bases its code generation on stepwise re- 
finement, we are generating all code directly from the 
state machines with fully automated transformations 
that can be proven correct. 

The next section gives a brief description of the syn- 
tax and semantics of RSML. Sections 3 describes a 
provably correct mapping from RSML to executable 
code and Section 4 presents the results from our case 
study. Section 5 concludes. 



2 The Semantics of RSML 

RSML was developed as a requirements specification 
language for embedded systems. The language is based 
on hierarchical finite state machines and is in many 
ways similar to Statecharts by David Harel. For ex- 
ample, RSML supports parallelism, hierarchies, and 
guarded transitions borrowed from statecharts (Fig- 
ure 1) [5, 8]. 
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Figure 2: A transition definition from TCAS II with the guarding condition expressed as an and/or table. 



One of the main design goals of RSML was read- 
ability and understandability by non computer profes- 
sionals such as, in our case, pilots, air frame manu- 
facturers, and FAA representatives. During the TCAS 
project, we discovered that the guarding conditions re- 
quired to accurately capture the requirements were of- 
ten complex. The propositional logic notation tradi- 
tionally used to define these conditions did not scale 
well to complex expressions and, thus, quickly be- 
came unreadable. To overcome this problem, we in- 
troduced a tabular notation for defining the guarding 
conditions (Figure 2). We call these tables and/or 
tables. The tables are read column-wise and were 
found to be very readable. To further increase the 
readability, we introduced many other syntactic con- 
ventions in RSML. For example, we allow expressions 
used in the predicates to be defined as mathematical 
functions (Other-Tracked-Relative-Alt-Ratef. 2 46) , and 
familiar and frequently used conditions to be defined 
as macros (lOO-Ft-Crossingm-ies) 1 . A macro is simply 
a named and/ OR table defined elsewhere in the doc- 
ument. A detailed description of the full notation can 
be found in [15]. 

2.1 A Functional Framework 

The behavior of a finite-state machine can be formally 
defined using a next-state relation. In RSML, this re- 
lation is modeled by transitions and the sequencing of 
events. Thus, one can view a graphical RSML specifi- 
cation as the definition of the mathematical next-state 
relation F. 

Section 2.2 defines the static structure of the state 

1 The subscript is used to indicate the type of an identifier (f 
for functions, m for macros, and v for variables) and gives the 
page in the TCAS II requirements document where the identifier 
is defined. 
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Figure 3: A sample state hierarchy 

hierarchies. Although we are using a different notation, 
the basic ideas for the formalization of the hierarchical 
structure of the state machines is borrowed from Harel 
et oi. [9]. Section 2.3 describes how the dynamic be- 
havior denned by the transitions and events in RSML 
can be viewed as compositions of functions. 

2.2 Hierarchical State Machines 

An RSML state machine M can be described by a six- 
tuple: M = (5, <, ~, V, co, F) where: 

5 is a finite set of states. 

< is a tree-like partial ordering with a topmost point 
(called the root). This relation defines the hierar- 
chy relation (or parent/child relation) on the states 
in S (x < y meaning that x is a descendant of y, 
or z and y are equal). 

In the graphical notation, this relation is visualized 
as containment (states are contained within super- 
states). In Figure 3, for example, B < A,G < 
A,I<E, etc. 

If the state x is a descendant of y (x < y A x ^ y, 
denoted by x < y) t and there is no z such that 
x < z < y, we say that the state x is a child of y 
(i child y). 



Furthermore, we define o(y) as the set of all chil- 
dren of the state y, that is, a(y) = {x \ x child y) 
~ is an equivalence relation on the states in S — {root} 
that satisfies one additional property: whenever 
x ~y % then x and y have the same parent. 
x ~ y 3z : x t y€a(z) 

The equivalence relation ~ is used to partition the 
children of a state into disjoint sets called parallel 
components. In the graphical notation, this parti- 
tion is indicated using dashed lines. In Figure 3, 
for example, the children of A are partitioned into 
two parallel components (equivalence classes) {B, 
C} and {D, E}. 

V is a set containing the input and output histories of 
the model (the complete variable traces). 

Go is the initial global state of the machine, cq € 
(Config x V). A global state is an ordered pair 
consisting of a set of states, called the configura- 
tion of the machine, and a trace from V. The 
initial global state in Figure 3 is defined by the 
pair ({A, B, D},0). 

F is a relation defining the global state changes in the 
machine AT. F is a mapping CkC, where C C 
{Config x V). The relation F is also referred to 
as the behavior of M . 

2.3 Next-State Mapping 

The hierarchies and parallelism (defined by the rela- 
tions < and ~), enforce a rigorous structure on the 
possible global states (the set C). The dynamic behav- 
ior (the possible global state changes) is defined by the 
next-state relation F (C »-> C). In a model of a system 
with nontrivial functionality this mapping will be com- 
plex- However, the mapping can be viewed as a compo- 
sition of smaller, less complex mappings. Specifically, 
F can be viewed as composed of simple functions. 

In the graphical notation, these simple functions are 
denned by transitions. The domain of a function is 
defined by the source, that is, the state that the tail 
of the transition is leaving, and the guarding condition 
on the transition. The image of a function is defined 
by the destination of a transition, that is, the state 
the transition enters, and possible changes to variables. 
The functions represented by the transitions are then 
composed depending on the structure of the particular 
state machine being considered and the events defined 
on the transition. The semantics of RSML are defined 
using three basic compositions: 

Union: The union composition of two functions (gUh) 
merges the domains of the functions. 

Serial: Serial composition g(h(c)) (or g o h) corre- 
sponds to normal functional composition. 

Parallel: Parallel application is denoted (h,g)(x). 
Parallelism is modeled as interleaving, that is, an 
arbitrary ordering of serial compositions. The no- 
tation (X), where X is a set of functions, will 
be used to denote the parallel composition of the 
functions in X. 




Figure 4: A sample state machine. 

In RSML, union composition occurs between non- 
parallel transitions triggered by the same event. For 
example, the functions representing the transitions t\ , 
*2> and *3 in Figure 4 (assuming all are triggered by 
the same event) are composed in union. 

Transitions triggered by the same event, but in par- 
allel state components, are composed in parallel. In 
Figure 4, transitions t$ and t* are composed in parallel 
(assuming they are triggered by the same event). 

Finally, serial application is caused by the event 
propagation mechanism. Assume the transition t$ is 
triggered by some external event and generates event 
e as an action. This event is picked up by transition 
te — that is, *e is triggered by e. Thus, transition * 5 is 
taken first and transition t$ second. This sequencing is 
modeled as applying the functions representing t$ and 
* 6 in series: /«, o/ t5 (c). 

A function / representing a transition can be textu- 
ally defined by 

/(c) = {(cConf - Q s ) u Q dt v) if (x € cConf) Ap(c) 

where Q 9 and Q& are sets of states, v is an updated 
variable trace, x is a state, and p is an arbitrary pred- 
icate over the global state c. The notation c.Con f is 
used to refer to the Configuration part of the global 
state c. In the graphical representation, this function 
represents a transition starting in the state x and with 
the guarding condition p. If the transition is taken, the 
structure of the state machine may cause more states 
than x to be exited — for example, if x is a superstate. 
The set of states that is exited when the transition is 
taken is denoted by Q B and the set that is entered by 
Qd- Qs and Qd are the source (5ource(/)) and desti- 
nation (Dest(f)) of / respectively. 

The functional definition of a complete RSML spec- 
ification is recursively built from (composed of) the 
functional definitions of its components. To define this 
recursion we need to introduce some auxiliary concepts. 

Let E be the set of all events in a model M. A tran- 
sition is denned by a tuple ((C >-+ C) x E x 2 B ). The 
components of the tuple are denoted by map, trigger, 
and actions respectively. The map function is defined 
as outlined earlier in this section. Let T be the set 



of all transitions. Furthermore, let Stages = S U II, 
where II is the set of equivalence classes of ~. Also, for 
any s € 5, let n(s) be the set of equivalence classes of 
children of s: 

*(s) = {x € n | x C <r(s)} 
For each f C T we will define a function 

p[t] : Stages (C h» G) 
that defines the behavior of states and parallel com- 
ponents given a set of trigger events. The function g 
is defined by induction on Stages over the relation 
defined as follows: 

For all s € S t p € II, and st 6 Stages 

s <&st iff st € II and s € at (1) 
p fit iff st G 5 and p e ?r(st) (2) 

Induction over «^ is valid because it is well-founded: 
Whenever ai <SC p fij, it follows that $i < 5a- There- 
fore, does not contain an infinite descending chain. 

The behavior of a composed state (a superstate) is 
defined as the parallel composition of its parallel state 
components. In Figure 4, for example, the behavior of 
the state A is defined as the parallel composition of its 
four parallel state components. 

Definition 1 For any p € II and tCT, the behavior 
{g) of a state s € 5: 

*M. = <{*[*]p Ip<£*» 

Informally, one can view the components of a composed 
state as processes, and the behavior of the composed 
state as the parallel execution of these processes. 

The behavior of a set of states grouped in a paral- 
lel state component is defined as the union of (1) the 
behaviors of the states included in the component and 
(2) the behaviors introduced by the transitions between 
states at this level of abstraction. Let the notation 
tr Zip (tr belongs to p) signify that a transition fr € T 
goes between two states in the parallel state component 
p. In Figure 4, the transition labeled with t± belongs to 
the parallel component {B t C}. 

Definition 2 A transition tr belongs to the parallel 
component p of a state s, that is, p € 
ir(s), (denoted by tr D p) iff: 

3a: 6 Source(tr.map) : x € p 

Definition 3 For any a € S and t C T, the behavior 
of a parallel state component p € II: 

9[t) P = ( (J 3[tU ) U ( (J tr.map) 

\m<p / VfretAtrDp / 

Informally, in a parallel state component, we will look 
for an applicable transition from the set of transitions 
between the states contained in this parallel component 
and among the transitions contained inside any of the 
states within the component. 



Finally, the behavior of a model M under a specific 
event e can be defined. Let T e be the set of all transi- 
tion with the trigger e € E, that is, 

T e = {tr € T | tr.trigger = e} 



Definition 4 The behavior of M under event e € E 
is defined as 

F* = g[T e ] root 

The rules defined above govern the behavior of M 
under one specific event, that is, all transitions in the 
model triggered by this one event are composed ac- 
cording to these rules. The behavior for all individual 
events in the model can now be modeled the same way. 
If an event e is generated, the function defined by the 
behavior under e (F e ), that is, the behavior generated 
by composing all transitions triggered by e, is applied, 
and a new system state is calculated. After a function 
has been applied and a new system state calculated, a 
new function is applied based on the output actions on 
the transitions used to construct the first function. We 
call the set of events generated as a result of output 
actions the yield of a next state calculation. 

A sequence of function applications will follow. The 
next function is always determined by the yield of the 
previous function. Should the yield contain more than 
one event, the appropriate functions are composed in 
parallel. This sequence ultimately will stop when the 
next state calculation provides no yield. 



3 Code Generation 

The relative simplicity of the RSML semantics allows 
it to be translated into high-level progr amming con- 
structs in a straightforward manner. In an attempt to 
make the generation of executable code easy to auto- 
mate, easy to trace, and straightforward to verify, we 
have chosen to make a one-to-one mapping from the 
formal definition of the semantics to executable code. 
This translation provides a provably correct implemen- 
tation of an RSML specification. However, such a di- 
rect approach introduces some inefficiencies in the gen- 
erated code. Fortunately, these inefficiencies can be 
largely addressed through automated correctness pre- 
serving optimizations. 

This section describes our translation approach and 
some optimizations are discussed in Section 4. 

As mentioned in the previous section, the behavior 
of a single transition is defined by the function 

/(c) = ((cConf - Q a ) U Q dt v) if (x G cConJ) Ap(c). 

The behavior of this single transition can be trivially 



bool STQ 

{ if ((x e c) and p){ 

c= cVQa; 
v = modify(v)\ 
return TRUE; } 
return FALSE; 

} 

Figure 5: Pseudo-Code implementing a single transi- 
tion. 

implemented by the following program: 

P: if 

((ar € cConf) Ap(c)) -> J 
-i((x € cConf) Ap(c)) skip 

e 

J : c.Conf = cConf - Q a ; 
cConf - cConf U Q d \ 
v — modify(v)\ 

The correctness of the above program is easily verifiable 
by a weakest precondition proof. 

The program in Figure 5 is the equivalent 
(pseudo)code for the program P, which executes a sin- 
gle transition upon occurrence of the trigger event. The 
return value will be used later during code generation 
to determine whether or not the transition was actually 
taken. 

In the following discussion of composed and parallel 
states, the functions ge\$ and ge\p correspond to the 
functions g[t] a and g[i\ p defined in the previous section. 
Here, these functions are viewed as responding to event 
ei, rather than executing transitions from set T which 
have trigger ei. Since the set of transitions can be 
determined at translation time there is no need to pass 
them as a parameter. The applicable transitions can 
simply be included directly into the code. 

The behavior of a composed state is defined as the 
parallel execution of its parallel components, where 
parallelism is modeled as arbitrary interleaving. Thus, 
if (pi, p2, pn) are the parallel components of state 
s that can respond to event e, then the program in Fig- 
ure 6 is one possible implementation of the behavior of 
composed state 5 (compare with Definition 1). 

Parallelism is deterministic only if the behavior of 
the system is equivalent for all possible serial orderings. 
If this is not the case, the behavior is nondeterrninistic, 
and this implementation simply executes one of the 
possible behaviors. 

The rules governing the behavior of a parallel com- 
ponent (union composition) can be modeled as a se- 
quential attempt to find a transition that can be taken, 
that is, attempt to find a function that has the current 
state in its domain. By definition, a parallel component 



void geis{) 
{ ffeiplQ; 

peipn(); 

} 

Figure 6: Pseudo-Code implementing the behavior of 
a composed state under the event ei . 

void geipQ 
. { if (STIO) 
return ; 
if(5T2()) 
return ; 

if(STnO) 
return ; 
pei3l(); 
geis2Q; 

geisnQ; 

} 

Figure 7: Pseudo-Code implementing the behavior of 
a parallel component under the event ei . 

can successfully execute only one transition in response 
to a single event (Definition 3), and the program in Fig- 
ure 7 enforces this behavior by immediately returning 
upon the successful completion of a single transition. 
(ST1, ST2, ... STn) are the corresponding functions 
for all transitions triggered by the event ei belonging 
to parallel component p, and (geisl, ge\s2 y ... geisn) 
are the functions denning the behavior (under the event 
d) of the the states that are children of p. Here the 
return value of the single transition function (ST in 
Figure 5) is used to exit the function upon success- 
ful execution of a transition. It should be noted that 
should there be nondeterminism, this implementation 
gives precedence to transitions at the highest level in 
the state hierarchy, which is not a requirement of the 
language. 

As discussed earlier, the behavior of an entire ma- 
chine under a specific event ei is simply ge\S TW> t- Thus, 
there is one ge\s roo t function for each possible event ci, 
and a function that responds to an arbitrary event e 
need only select the proper function ges r oot to call. The 
program in Figure 8 implements this behavior, where 
(ei, e% y e n ) are all events in the machine. 

The event propagation (the sequence of function ap- 
plications) can be modeled using two sets. One set 
(toProcess) to hold the events currently being evalu- 
ated and another set (yield) to collect the yield from 



void execute(Event e) 
{ switch (c) { 

case ei : geiS r oot(); break; 

case e 2 : pe2S roo tO; break; 

case en : pe„s r oo*(); break; } 

} 

Figure 8: Pseudo-Code implementing the selection of 
function based on trigger event 

set(Event) toProcess; 
set{Event> yield; 
void input(Event e) 
{ toProcess.insert(e); 
bool moreEvents = TRUE; 
while (moreEvents) { 

for (each event e in toProcess) { 
execute(e); } 

if (yield.empty()) 

moreEvents = FALSE; 
else{ 

toProcess = yield; 

yield = emptySet; } } 

> 

Figure 9: Pseudo-Code implementing the sequence of 
transitions caused by the event-action semantics. 

the transitions taken. When all events in toProcess 
have been processed, the events in yield are copied to 
toProcess and the a new evaluation can start. This 
cycle is repeated until we have an empty yield (com- 
pare the discussion of yield in Section 2). A function 
implementing this behavior can be seen in Figure 9. 

Note also that the function implementing the behav- 
ior of the individual transitions must include code to 
put their actions into the yield set. Thus, the revised 
function for a single transition can be seen in Figure 10. 

The code described in this section corresponds one- 
to-one with the formal definition of RJSML. This simple 
implementation makes proofs of consistency between 
specification and implementation trivial. 

To get a fully executable system, the only miss- 
ing pieces are the input and output interfaces to the 
environment. The input and output mech anisms are 
often highly system dependent and usually not mod- 
eled in detail in a high-level specification. We are cur- 
rently investigating how RSML can be augmented with 
a communications model that will allow us to generate 
code for hardware independent input and output mod- 
ules. To make a fully executable system, the hardware 



bool 5T() 
{ if(x € c) 

if(p){ 
c = c-Q B \ 
c = cUQ d ; 
v = modiJy(v)\ 
yield .insert{action3) ; 
return TRUE; } 
return FALSE; 

} 

Figure 10: Modified code for a single transition 

dependent code must be added separately. For now, 
however, we will just assume that modules exist for 
receiving messages from and sending messages to the 
environment. The input interfaces need simply receive 
a message from the environment, assign appropriate 
input variables, and pass the corresponding event to 
the input function to begin machine execution. Out- 
put interfaces are triggered by events generated while 
executing the machine. Thus, when an event is gener- 
ated that is a trigger to an output interface, a call to 
the appropriate interface module can be made. 

4 Case Studies 

Two of the main impediments to widespread use of 
automatic code generation are code size and code effi- 
ciency: generated code is often unacceptably large and 
has poor run-time performance. The goal of our re- 
search is to develop a translation approach that will 
generate code of both acceptable size and acceptable 
performance. This is an ambitious goal. In many ap- 
plications even using a compiler to translate from a 
high-level language such as C++ or Ada leads to un- 
acceptably large and inefficient executables. Highly op- 
timized hand coded assembly is still used in many time 
and space critical applications, for example, in the au- 
tomotive industry [17]. Nevertheless, our goal is to be 
able to generate code that is efficient enough to be used 
in all but the most time and space critical applications. 

To evaluate our approach and to get an indication of 
how automatically generated code compares to manu- 
ally written code, we performed some small case stud- 
ies. 

We applied our technique to a subset of the TCAS 
n requirements specification [13, 15]. We translated 
a portion of the specification that determines the set- 
ting of a collection of aircraft parameters, for example, 
the effective sensitivity level (Effective-SL) that is a 
concept that determines how early to issue a collision 
warning to the pilot and Descend- Inhibit that deter- 
mines if an aircraft is prohibited from descending (the 
state machine representing these parts of TCAS can be 
seen in Figure 11). 




Figure 11: The state machine (Own- Aircraft) used in our case study. 



Descend-Inhibit 



Inhibited 



Not-Inhibited 



Figure 12: The state machine for Descend-Inhibit 



Transition(s): j Inhibited | — » | Not-Inhibited 1 
Location: Own- Aircraft > Descend-Inhibits-so 

TVigger Event: Surveillance- Complete-Evente_279 
Condition: 

| (Own-Tracked- Alt - Ground-Level) < 12,00ft | |"T~| 
Output Action: Descend-Inhibit- Evaluated- Evente-279 



The pseudo-code outlined in the previous section can 
trivially be translated into executable code. In our case 
we chose C++, but any high-level language would be 
appropriate. 

Consider the state machine for Descend-Inhibit in 
Figure 12 and the definition of the transition from the 
state Inhibited to the state Not-Inhibited (Figure 13). 
The C++ code corresponding to the state machine can 
be seen in Figure 14, and the code for the transition (or 
function) in Figure 13 is shown in Figure 15. The C++ 
code has a one-to-one correspondence to the pseudo- 
code in the previous section (compare the code with 
Figures 6 and 10). 

We compared the efficiency and size of the auto- 
matically generated code with code derived from an 
English language and pseudo-code specification of the 
same system. The programs were compared on a set 
of test suites ranging from a few inputs to more than 
a million inputs. 

While initial observations were somewhat disap- 
pointing (the generated code was approximately two 
times larger and approximately 30 times slower than 
the manually generated code), an analysis of the gener- 
ated code uncovered several possibilities for automated 
optimizations which, when applied, significantly im- 
proved the efficiency of the generated code. 

Optimizations : One of the first areas where the gen- 
erated code demonstrates inefficiency is in the large 



Figure 13: The transitions out of Inhibited 

void Descend-Inhibit () 
{ if (Inhib.to.NotlnhibO) return; 
if (NotInhib_to_XnhibO) return; 

> 

Figure 14: The C++ code for the state machine 
Descend-Inhibit 

bool Inhib_to_MotInhib() 

{ if (isInConfig(DI.INHIBITED)) 

if (0TrackAlt_Minus_GL_GT.12OO () ) -C 
removeFromConf ig(DI_ INHIBITED) ; 
addToConf ig (DI.NOT.INHIBITED) ; 
Yield, insert (DESC.IN.EVAL.EVENT) ; 
return true;} 
return false; 

> 

Figure 15: The C++ code for the transition from In- 
hibited to Not-Inhibited 



bool STQ 

{ if (P){ 

c = c- Q 9 \ 
c=cUQ d ; 
v = modify(y)\ 
yield. insert {actions); 
return TRUE; } 
return FALSE; 

} 

Figure 16: Code for single transition with check for 
source state removed. 

void gepQ 

{ if((xl €c)&& ST1Q) 
return ; 
if((x2€c)&& ST2Q) 
return ; 

if ((xn € c)&& STn{)) 
return ; 

geslQ; 
9es2Q; 

gesnQ; 

} 

Figure 17: Code for parallel component including check 
for source state. 

number of function calls that must be made to find a 
transition that *~ ar> be taken. The transitions triggered 
by an event are simply searched until an applicable 
transition is taken. A transition can only be taken, of 
course, if its source state is in the current configura- 
tion, and this test is done in the transition function 
(Figure 10). The first step in optimizing the code is 
thus to move this test for the source state's presence in 
the configuration into the calling function, the parallel 
component function (Figure 7). The resulting transi- 
tion function and parallel component function can be 
seen in Figures 16 and 17. 

This optimization allows the presence of a state in 
the configuration to be tested earlier and avoids a func- 
tion call if the state is not in the configuration. The 
performance gain realized by this optimization is rather 
small, but it enables another optimization to be per- 
formed that will have a greater impact on the overall 
efficiency of the generated code. 

The second optimization involves the repeated 
queries of the configuration to test for a state's pres- 
ence. Looking at the modified code for a parallel com- 
ponent function (Figure 17), note that a query for the 
presence of a state in the configuration is made for 



void gepQ 

{ switch (childActive(p)) { 
case xl : 

if (ST1()) return; 

gesl{); 

break; 
case x2 : 

if (ST20) return; 

$es2(); 

break; 

case xn : 

if (STn()) return; 

gesnQ] 

break; } 



Figure 18: Further optimized code for parallel compo- 
nent. 



eac h transition that is tested. If all queries could be 
reduced to one, a significant performance gain may be 
realized. This optimization was implemented by defin- 
ing a function childActive(p) that returns the currently 
active child state of parallel component p. A parallel 
component can have only one active child state, and 
thus a single query of the configuration can determine 
which of the transitions may be applicable, that is, have 
their source states in the current configuration. The 
modified parallel component function can be seen in 
Figure 18. 

The optimized generated code provided sig nificant ly 
better results than the unoptimized code. The opti- 
mized code was still approximately twice as large as 
the hand-generated code, but execution time was now 
only five times slower than the highly optimized hand- 
generated code. 

The approach has also been applied to two addi- 
tional small RSML specifications. In these cases the . 
code was approximately 8 and 13 times slower than 
highly optimized hand-generated code. The size of the 
automatically generated code was about 10% larger 
than the hand-generated code in each case. 

To summarize, the basis of our approach— the one- 
to-one mapping from specification to code— generated 
easily verifiable but inefficient code. However, by ap- 
plying some obvious, fully automated, correctness pre- 
serving optimizing transformations the efficiency of the 
code can be significantly increased. By taking advan- 
tage of additional optimizations, for example, using the 
lazy evaluation of Boolean expressions in C++ when 
evaluating large guarding conditions, we believe the ef- 
ficiency of the generated code can be comparable to 
efficient hand written code. 



5 Summary and Conclusion 

Experience has shown RSML to be an excellent tool for 
the modeling of safety-critical embedded control sys- 
tems. However, without a means of formally verify- 
ing consistency between specification and implementa- 
tion, there is no guarantee that the final implementa- 
tion matches the specification. Automatic code gener- 
ation offers the guarantee of correctness, as well as a 
significantly simplified and shortened development cy- 
cle, allowing the developers to concentrate on correctly 
specifying the system and validate its behavior rather 
than trying to overcome obscure implementation de- 
tails. 

Several other systems that generate code from speci- 
fications require the user to extensively guide the trans- 
lation process, thus reducing the benefits of code gener- 
ation. Because of the relative simplicity of the formal 
semantics of RSML and RSML's focus on a particu- 
lar problem domain, fully automatic, provably correct 
code generation is possible. 

In this paper, we outlined our approach for code 
generation from an RSML requirements specification 
to an implementation in C++. Our approach is based 
on a one-to-one mapping between the formal semantics 
of RSML and an implementation in a high-level lan- 
guage, in our case C++. The simplicity of the transla- 
tion makes it trivial to verify its correctness. However, 
such a straightforward translation introduces inefficien- 
cies in the generated code, lb overcome this problem 
we apply fully automated, correctness preserving op- 
timising transformations that eliminate obvious ineffi- 
ciencies. 

Tb evaluate the feasibility of the approach, we com- 
pared the efficiency and size of the generated code with 
highly optimized hand written code. In this small case 
study the generated code was approximately one order 
of magnitude slower and twice as large as hand gener- 
ated code. We are currently evaluating additional op- 
timizations and we are convinced that it is possible for 
the generated code to achieve comparable performance 
to hand written code. 

In addition to further applications of optimizations 
to the generated code, other future investigations will 
include the formulation of strategies to generate code 
for the remaining parts of RSML including input and 
output interfaces and timing constructs. Furthermore, 
more rigorous case studies of the performance of gener- 
ated code will be conducted, including its performance 
on machines of various sizes and structures. 
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